ICAP Interface Support
ICAP Interface Support
 
This chapter provides information on configuring the external Active Content Filtering servers for a core network service subscriber. This chapter also describes the configuration and commands that are used to implement this feature.
It is recommended that you select the configuration example that best meets your service model, and configure the required elements for that model, as described in respective product Administration Guide, before using the procedures in this chapter.
The following products currently support ICAP interface functionality:
•
GGSN
•
P-GW
ICAP Interface Support Overview
This feature supports streamlined ICAP interface to leverage Deep Packet Inspection (DPI) to enable external application servers to provide their services without performing DPI, and without being inserted in the data flow. For example with an external Active Content Filtering (ACF) Platform.
A high-level view of the streamlined ICAP interface support for external ACF is shown in the following figure:
High-Level View of Streamlined ICAP Interface with external ACF
The system with ECS is configured to support DPI and the system uses this capability for content charging as well.
If a subscriber initiates a WAP (WAP1.x or WAP2.0) or Web session, the subsequent GET/POST request is detected by the DPI function. The URL of the GET/POST request is extracted and passed, along with subscriber identification information and the subscriber request, in an ICAP message to the application server. The application server checks the URL on the basis of its category and other classifications like, type, access level, content category and decides if the request should be authorized, blocked, or redirected by answering to the GET/POST with:
•
A 200 OK message if the request is accepted
•
A 302 Redirect message in case of redirection. This redirect message includes the URL to which the subscriber should be redirected
•
A 403 Denied message is the request should be blocked
Depending on the response received, the system with ECS will either pass the request unmodified, or discard the message and respond to the subscriber with the appropriate redirection or block message.
Content charging is performed by the Active Charging Service (ACS) only after the request has been controlled by the application server. This guarantees the appropriate interworking between the external application and content-based billing. In particular, this guarantees that charging will be applied to the appropriate request in case of redirection, and that potential charging-based redirections (i.e. Advice of Charge, Top Up page, etc.) will not interfere with the decisions taken by the application server.
Functions of the ACF include:
•
Retrieval of subscriber policies based on the subscriber identity passed in the ICAP message
•
Determining the appropriate action (permit, deny, redirect) to take for the type of content based on subscriber profile
•
Communication of the action (permit, deny, or redirect) decision for the URL back to the ACS module
Failure Action on Retransmitted Packets
ICAP rating is enabled for retransmitted packet when default ICAP failure action was taken on an ICAP request for that flow. ICAP default failure action is taken on the pending ICAP request for a connection when the connection needs to be reset and there is no other redundant connection available. For example, in the ICAP request timeout and ICAP connection timeout scenarios. In these cases the retransmitted packet in the uplink direction is sent for ICAP rating again.
In case of WAP CO, uplink retransmitted packet for the WAP transactions for which ICAP failure action was taken will be sent for ICAP rating. WSP header of the retransmitted packet is not parsed by the WSP analyzer. The URL received in the previous packet for that transaction is used for ICAP rating. If failure action was taken on multiple WTP transactions for the same flow (case: WTP concatenated GET request) then uplink retransmitted packet for each of the transaction is sent for rating again.
In case of HTTP, uplink retransmitted packets for the HTTP flow on which ICAP failure action is taken is sent for ICAP rating. The URL present in the current secondary session (last uplink request) is used for ICAP rating. However, if there were multiple outstanding ICAP request for the same flow (pipelined request) then for the retransmitted packet the URL that will be sent for rating will be that of the last GET request.
Retransmission in various cases of failure-action taken on re-transmitted packets when the ICAP response is not received for the original request and the retransmitted request comes in:
•
WSP CO:
•
Permit: The uplink packet is sent for ICAP rating and depending on the ICAP response the WTP transaction is allowed/blocked. It is possible that the WAP gateway sends the response for the permitted GET request. Hence, there is a race condition and the subscriber may be able to view the web page even thought the rating was redirect or content insert.
•
Content Insert: The retransmitted packet is not sent for ICAP rating.
•
Redirect: The retransmitted packet is not sent for ICAP rating.
•
Discard: The uplink packet is sent for ICAP rating and depending on the ICAP response the WTP transaction is allowed/blocked.
•
Terminate flow: The uplink packet is sent for ICAP rating and depending on the ICAP response the WTP transaction is allowed or blocked. The WAP gateway may send an Abort transaction for this GET request if the WSP disconnect packet sent while terminating the flow is received by the WAP gateway.
•
HTTP:
•
Permit: The uplink packet is sent for ICAP rating and depending on the ICAP response the last HTTP GET request. It is possible that the HTTP server sends the response for the permitted GET request. Hence there is a race condition and the subscriber may be able to view the web page even thought the rating was redirect or content insert.
•
Content Insert: Retransmitted packets are dropped and not charged.
•
Redirect: Retransmitted packets are dropped and not charged.
•
Discard: The uplink packet is sent for ICAP rating and depending on the ICAP response the WTP transaction allowed/blocked.
•
Terminate flow: Retransmitted packets are dropped and not charged.
Supported Networks and Platforms
This feature supports ST16 and Cisco Chassis for the core network services configured on the system.
License Requirements
External Content Filtering Server support through Internet Content Adaptation Protocol (ICAP) interface is a licensed Cisco feature. A separate feature license may be required. Contact your Cisco account representative for detailed information on specific licensing requirements.
For information on installing and verifying licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.
Configuring ICAP Interface Support
This section describes how to configure the Content Filtering Server Group (CFSG) through Internet Content Adaptation Protocol (ICAP) interface between ICAP client and ACF server (ICAP server).
note_smallImportant: This section provides the minimum instruction set for configuring external content filtering servers on ICAP interface on the system. For more information on commands that configure additional parameters and options, refer to CFSG Configuration Mode Commands chapter in Command Line Interface Reference.
To configure the system to provide ICAP interface support for external content filtering servers:
Step 1
Create the Content Filtering Server Group and create ICAP interface with origin (local) IP address of chassis by applying the example configuration in the Creating ICAP Server Group and Address Binding section.
Step 2
Specify the active content filtering server (ICAP sever) IP addresses and configure other parameters for ICAP server group by applying the example configuration in the Configuring ICAP Server and Other Parameters section.
Step 3
Configure the content filtering mode to external content filtering server group mode in ECS rule base by applying the example configuration in the Configuring ECS Rulebase for ICAP Server Group section.
Step 4
Optional. Configure the charging action to forward HTTP/WAP GET request to external content filtering servers on ICAP interface in Active Charging Configuration mode by applying the example configuration in the Configuring Charging Action for ICAP Server Group section.
Step 5
Verify your ICAP interface and external content filtering server group configuration by following the steps in the Verifying the ICAP Server Group Configuration section.
Step 6
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Creating ICAP Server Group and Address Binding
Use the following example to create the ICAP server group and bind the IP addresses:
configure
  context <icap_ctxt_name> [ -noconfirm ]
     content-filtering server-group <icap_svr_grp_name> [ -noconfirm ]
        origin address <ip_address>
        end
Notes:
•
<ip_address> is local IP address of the CFSG endpoint.
Configuring ICAP Server and Other Parameters
Use the following example to configure the active content filtering (ICAP server) and other related parameters:
configure
  context <icap_context_name>
     content-filtering server-group <icap_server_grp_name>
        icap server <ip_address> [port <port_number>][max <max_msgs>][priority <priority>]
        deny-message <msg_string>
        response-timeout <timeout>
        connection retry-timeout <retry_timeout>
        failure-action {allow | content-insertion <content_string> | discard | redirect-url <url> | terminate-flow}
        dictionary {custom1 | custom2 | standard}
        end
Notes:
•
In StarOS 8.1 and later, a maximum of five ICAP servers can be configured per Content Filtering Server Group. In StarOS 8.0, only one ICAP Server can be configured per Content Filtering Server Group.
•
The maximum outstanding request per ICAP connection configured using the optional max <max_msgs> keyword is limited to one. Therefore, any other value configured using the max keyword will be ignored.
•
Optional. To configure the ICAP URL extraction behavior, in the Content Filtering Server Group configuration mode, enter the following command:
url-extraction { after-parsing | raw }
By default, percent-encoded hex characters in URLs sent from the ACF client to the ICAP server will be converted to corresponding ASCII characters and sent.
Configuring ECS Rulebase for ICAP Server Group
Use the following example to configure the content filtering mode to ICAP server mode in the ECS rulebase for content filtering:
configure
  require active-charging [optimized-mode]
  active-charging service <acs_svc_name> [-noconfirm]
     rulebase <rulebase_name> [-noconfirm]
        content-filtering mode server-group <cf_server_group>
        end
Notes:
•
In StarOS 8.1, the optimized-mode keyword enables ACS in the Optimized mode, wherein ACS functionality is managed by SessMgrs. In StarOS 8.1, ACS must be enabled in the Optimized mode.
•
In StarOS 8.3, the optimized-mode keyword is obsolete. With or without this keyword ACS is always enabled in Optimized mode.
•
In StarOS 8.0 and StarOS 9.0 and later, the optimized-mode keyword is not available.
Configuring Charging Action for ICAP Server Group
Use the following example to configure the charging action to forward HTTP/WAP GET request to ICAP server for content processing:
configure
  active-charging service <acs_svc_name>
     charging-action <charging_action_name> [ -noconfirm ]
        content-filtering processing server-group
        end
Verifying the ICAP Server Group Configuration
This section explains how to display and review the configurations after saving them in a .cfg file and also to retrieve errors and warnings within an active configuration for a service.
note_smallImportant: All commands listed here are under Exec mode. Not all commands are available on all platforms.
These instructions are used to verify the configuration for this feature.
Step 1
Verify your ICAP Content Filtering Server Group configuration by entering the following command in Exec Mode:
show content-filtering server-group
The following is a sample output. In this example, an ICAP Content Filtering server group named icap_cfsg1 was configured.
Content Filtering Group:     icap_cfsg1
  Context:                     icap1
  Origin Address:              1.2.3.4
  ICAP Address(Port):          1.2.3.4(1344)
  Max Outstanding:             256
  Priority:                    1
  Response Timeout:      30(secs)      Connection Retry Timeout:      30(secs)
  Dictionary:                   standard
  Timeout Action:               terminate-flow
  Deny Message:                 "Service Not Subscribed"
  URL-extraction:                after-parsing
  Content Filtering Group Connections: NONE
Total content filtering groups matching specified criteria:  1
Step 2
Verify any configuration error in your configuration by entering the following command in Exec Mode:
show configuration errors
 
 
Cisco Systems Inc.
Tel: 408-526-4000
Fax: 408-527-0883